Dietmar

I just found, that there is a mechanical(!) switch on this crazy RJ45 connector of this laptop. I come to this idea, because Win10 also does not show the Realtek 8168 network device in Device Manager. And you cant use any RJ45 cable. It needs to have this clip, or the mechanical switch is not fulfilled. So with via this switch, I get this RJ45 lan port to work in win10, but not in XP. Oh.., what a downgrade in quality from Lenovo in this notebook compared with the x230 notebook. The x230 notebook is from 2013, but it has in every point better benchmarks as this G50-80, both i7, and quality is 1000% plus Dietmar "Yes, the Lenovo G50-80 does feature a type of mechanical switch within the RJ-45 port. This switch is part of the port's design to allow for a slim profile, often referred to as a "folding" or "drop-jaw" RJ-45 connector. When you insert an Ethernet cable into the port, a small hinged piece inside the port moves to accommodate the connector, effectively creating the necessary contact points for the Ethernet connection. This design is common in many modern slim laptops to save space while still providing a full-sized Ethernet port."

Here is the DSDT, also dsdt.raw of the Lenovo g50-80 together with its Bios, fetched from this notebook. May be, someone can see better than me, where the big sleeping for USB and also for Lan happens Dietmar https://ufile.io/60o5g5ux

@DaniiX Hi, I nearly get all to run under XP SP3 on Lenovo G50-80 from 2015/2016 notebook with Intel i7-5500U, 2x8GB DDR3 SoDIMM, Intel Graphics 5500, Radeon M330. Only the USB driver shows "unknown" device. This behavior I know from past while experimenting with @daniel_k, the sleeping mode is active in its USB Hub in DSDT in Bios. I will compare different Bios for this notebook, if I find one with not sleeping for the xhci driver in its DSDT. If not, I will edit DSDT in Bios by hand. What you have to do for XP SP3 install: 0.) Disable all "Secure" in Bios (Hit the very small button for to go to Bios Setup , next to the power connector.) 1.) UMA graphic disable. 2.) At the last (boot page) in Bios set "Win81 OS" to "Other OS". 3.) Enable "Legacy" mode. Dietmar PS: Without any risk of Bios modd the DSDT modd can be done with the nice ACPI Patcher at boot time from @Mov AX, 0xDEAD . EDIT: The Lan driver for the RJ-45 with DEV_8168 works, but does always show: "no network cable connected". Crazy, I think, this is also the symptom of deep sleep for the Lan driver. Crazy, what manufacturers around 2015 did for crazy things, for no longer enable XP install^^..

@reboot12 For the UEFI XP SP2 bit64 12900k cpu, you also need to install the modded hal.dll and intelppm.sys for XP SP2 bit64 Dietmar PS: Here they are. Now, really everything works for pure UEFI boot on GPT on the Gigabyte z690 UD DDR4 board for XP SP2 bit64. I installed those files by hand. https://ufile.io/95vlrwgr

Here comes pic from XP SP2 bit64 on GPT harddisk on pur UEFI with working(!) graphik, nice work from Gelip @reboot12 waaoohh.. Dietmar

@reboot12 It is not because of the compi hardware. The problem is the medium itself. Winhex "decides", if RAW copy is possible or not. But @Dave-H is correct, it is a little bit off topic here Dietmar

@reboot12 No. It is a fundamental problem of a modern medium, that is not a harddisk. The real speed of data transfer is not much more than 10MB/s on them on a loong run, even they show crazy high values. This is true also for Win10. The only exception from this is the Intel Optane storage, which was cut. This storage medium OPTANE even dont need TRIM Dietmar

@Dave-H I think about, where to post this yesterday evening. But I think, this is really important, and so I decided to post here, because I know, that a lot of people read here, sorry, Dietmar

@reboot12 With smaller USB stick, there is never a difference via "Copy Block" vs "Clone whole disk". The answer is, as ChatGPT tells: The internal logic of an USB stick changes time by time the "LBA to real adress" on stick Dietmar EDIT: I just check your times for copy. The Kingston has 64 GB. 64*1.5 min= 96 min. This is EXACT my time, that the "Clone whole disk" of my Kingston stick needs, 11MB/s. But with "Copy Block" exact only 24 min. It is even more crazy: For a whole image of my System WD harddisk with 2TB, via "Copy Block" I need only 3 hours. So, the transferspeed of this nice WD 2TB harddisk is 185 MB/s on a really loong run. Here you see at once the "good and fast modern world" ^^..

@reboot12 My Winhex is 11.9. Funny, my old Winhex copies without internal intelligence all, what it is offered, bit by bit Dietmar EDIT: Just now, my *.img from the Kongston USB3 stick is ready. Now, Winhex shows no differences to the USB stick and this *.img. This means, my version of Winhex copies indeed the actual block of everything correct and the USB stick is also correct. And this RAW copy is 4 times faster.

@reboot12 You can select a block in Winhex, for a given file. I use this method for the whole USB3 stick. It is ultrafast. Now I understand what happens: These raw data via "Block Copy" are exact that one, that stays on the USB3 stick at the moment, when it was copied. But other than on a harddisk, there is NO one by one LBA adressing to the real Values in an USB3 stick. The internal logic of the USB3 stick changes this data, as it think, that it is useful, crazy, for example not to write to the same memory too much, or to overjump errors Dietmar The behavior you observed is due to the fundamental differences in how data is managed on USB3 sticks compared to hard disks. Wear leveling, garbage collection, and ECC on USB sticks introduce complexities that raw block copying cannot handle correctly, leading to discrepancies in bit-by-bit comparisons. However, file-level integrity is maintained through the file system, ensuring that restored files are accurate.

@reboot12 This is, what ChatGPT tells about the difference of both copy methods via Winhex. But for me it is still strange: Does it mean, that Winhex copies the Checksum always between the files??? It seems, that Winhex indeed does a check of every sector, that it has been copied correct. But the mystery remains: The data on an USB3 stick are other stored other (geometrie, sectors???) than on a harddisk Dietmar Winhex: Image File (Whole Physical Disk Copy): Objective: Create a complete copy of the entire disk, including all sectors, both used and unused. Additional Tasks: Checksum Calculation: To verify the integrity of the copied data. File System Metadata Handling: Reading and writing file system metadata to ensure a faithful reproduction of the disk's structure. "Copy Block" Mode: Objective: Copy specific blocks or sectors of the disk as specified by the user. No Additional Tasks: No Checksum Calculation: Since only specific blocks are copied, there's no need to verify the entire disk's integrity. Ignoring File System Metadata: Focuses solely on the data within the specified blocks without considering the overall file system structure. Impacts on Duration: Image File: Longer Duration: Due to the comprehensive nature of the task, including checksum calculation and file system metadata handling. Advantages: Higher Data Security: The checksum ensures that the data integrity can be verified. Complete Copy: Includes all data, which is beneficial for forensic analysis and full data recovery. "Copy Block" Mode: Shorter Duration: Faster as it copies only specified blocks and skips additional tasks. Advantages: Efficiency: Suitable for situations where only specific parts of the disk are needed. In summary, creating an image of the whole physical disk is more thorough and secure but takes longer, while the "copy block" mode is quicker and more efficient for targeted data copying. 4o

@reboot12 I am just trying your method for the Kingston USB3 stick. This operation needs 4 times longer than my method of to copy the USB stick just as a whole block via Winhex. Do you know, if via your method Winhex makes a check, if the copied data are the same as the original ones? Because there must be a reason for time delay. Still the mystery in the behavior of USB3 sticks in my post above stays. Because there is no error at all after crazy checks, but different structure in the stored data from the USB stick, compared with the structure from a harddisk via Winhex. I use my last acpi.sys from the Ramsey XP SP3 and also the USB3 driver from there (nice for USB3 boot modded driver from @Mov AX, 0xDEAD) on a Gigabyte z690 UD DDR4 board, 12900k with 32 GB ram. Before I noticed real errors in any USB3 driver that I tested, when I copy millions of files one by one from the USB stick to the harddisk. And this errors happen also under Win10, 64 bit Dietmar

Hi, I make a test with two USB3 sticks: Kingston Workspace Datatraveler 64 GB and Sandisk Extreme Pro USB 3.1 256 GB Both sticks show a transferrate of more than 300 MByte/s and until now I am happy with them. Because on both sticks are important files from me, today I make a one by one bit copy via WinHex from the whole USB stick each. Both USB sticks have few bytes left free. And I store this result on a brandnew harddisk WD2003FZEX as*.dat file each. This 2TB Sata harddisk is manufactured in the end of 2023 in Taiwan, solid as much as possible. But now comes my bad surprise: Via Winhex I compare the content of the original USB stick with its *.dat file on this harddisk. Millions of errors are shown. This I have never seen before. When I transfer data between two of those harddisks from 2TB of WD, the error rate is <10^(-14) , means no error(!) in whole 2000 Gigabyte. Just now I am checking, what is going on. I copy the *.dat file back to such another, empty brandnew WD harddisk. and compare the result via Winhex of correctness. Then with with Beyond Compare I check, if there are really errors in the data, or if the crazy USB3 bus copies the space between datas not correct. Just now I think, that even expensive USB sticks are bad as much as possible for to store sensitive data Dietmar EDIT1: As expected, because of the ultrahigh quality of those harddisks, not a single error is shown between the *.dat files and their copy to this brandnew harddisk. EDIT2: The file compare via Beyond Compare 4 shows for 77 different files (all located on the USB stick) the message "stream error, cant compare". So, what does this mean? The error is indeed located on the USB stick, the information cant be read out any longer from that USB stick. Winhex shows during copy no error. In my Winhex versionit is no possibility to check, if a copy has been done successful. Crazy, those 77 files are gone (no, see Edit3). Some big, some small.. EDIT3: Oh crazy, I check by hand some of the files on the USB stick, that cant be read by Beyond Compare 4. They work. All is ok with them. So I run another check with Beyond Compare 2. All files are now shown as identic. What does this mean? The USB stick is not that bad as I thought. Bad is Beyond Compare 4. Nice works Beyond Compare 2 and it is even much faster. And: The files are stored on an USB stick, so that Winhex cant read them out one after the other as on a harddisk. EDIT4: This also means, that you can make with Winhex a correct bit by bit data copy from an whole USB stick. And restore after also correct all the files from such a *.dat file. But the structure in such a *.dat file from an USB stick is different to the structure for the same files(!) via harddisk. Would be interesting if somebody here in the forum can put some light on this behavior of an USB stick.

@K4sum1 Here is the same as Skull2 for server 2003 bit32 https://ufile.io/3a7684oj For XP SP2 bit64 I would use skull2 acpi.sys, because for you it is the one, which matches exact your Bsod. By the way, what shows the first of the 3 acpi.sys for bit64, where I cancel out (dirty hack) the Bsod 0xA5 (0x03, ...) itself Dietmar

@Joaquim Is the Lan activated in Bios? May be, that there is a conflict between the wireless driver and the RJ45 lan Dietmar

@Joaquim I think, you have to install XP SP3 new. And also the harddisk can have Physical errors after loong time Dietmar

@K4sum1 I just see, that the acpi BSOD 03 is in acpi.sys bit64 other handled as in acpi.sys bit 32. Here comes now the crazy hacked XP SP2 bit 64 version, where to 100% THIS BSOD never will happen again Dietmar PS: I find also the reason for this Bsod: C0140008 but I cant locate the exact place, where it happens: ValidateArgTypes or CreateField or ObjTypeSizeOf. This is a really evil Bsod. Maybe idea for hack from Skull is better - 0xA5(0x03, ..., C0140008, ...) DSDT code have operation with unexpected type of arguments, partially solved This BSOD probably means some argument has datatype, allowed only in ACPI 2.0 Patch: - _ValidateArgTypes must always return "OK", even on realy wrong types (mov edi, 0xC0140008=>mov edi, 0x00000000 at head of _ValidateArgTypes) https://ufile.io/sepw9iul and the much more nice solution from Skull https://ufile.io/u42mdknr or this one, only modded for ValidateArgTypes https://ufile.io/463tiqvh

@K4sum1 This kind of Bsod is not possible with this acpi.sys Dietmar

@Joaquim I think, you have to install the Lan driver new. Here it is Dietmar https://ufile.io/nkbuou9w

@K4sum1 Here it is. This was the latest one, that I build from Sources Dietmar https://ufile.io/zkdrmcs7

@K4sum1 I think, that the original acpi.sys has been copied back. This acpi Bsod is now impossible with the last acpi.sys from Ramsey Dietmar

@DaniiX I am not sure, what the reason for the not working keyboard is. May be it is an hidden Bsod, and the compi does not react at all. This can happen, if your harddisk is not correct formatted with MBR, force LBA, ntfs and ntldr. It can also be, that you need a special driver for this keyboard. You can test different USB drivers from Ramsey Dietmar

@user57 You can easy get all those updates via https://legacyupdate.net/ Because this lasts very long, I always use after XP SP3 install the updates first from https://winfuture.de/downloadvorschalt,2136.html and then the updates from Ramsey and the rest via legacyupdate.net Dietmar PS: There is via those updates always the error in the msi installer. This you have to solve by hand via Click Start, click Run, type MSIEXEC /UNREGISTER, and then click OK. Click Start, click Run, type MSIEXEC /REGSERVER, and then click OK.