Jump to content

Dietmar

Member
  • Posts

    1,245
  • Joined

  • Last visited

  • Days Won

    5
  • Donations

    0.00 USD 
  • Country

    Germany

Dietmar last won the day on August 23 2023

Dietmar had the most liked content!

About Dietmar

Profile Information

  • OS
    XP Pro x86

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dietmar's Achievements

268

Reputation

  1. I find the part for the Realtek 8168 in DSDT: It has name Glan. Here is the code after modd, for to overcome any sleeping of the Lan driver. For this, I have to use Iasl from 2014(!) or a lot of errors appear. EDIT: I succeed to boot modded DSDT with the nice Acpi_Patcher at boottime from @Mov AX, 0xDEAD, but it does not help. Now I even dont see the Realtek device 8168 in Device Manager. I have to remember to use for the Acpi Patcher the DSDT from running compi, not from Bios or get Bsod 0x7E 0xc0005. I think, I have to look in DSDT for the mechanical switch at the RJ-45 connector. But I have no idea for what I have to look in DSDT for this switch Dietmar Device (GLAN) { Name (_ADR, 0x00190000) // _ADR: Address OperationRegion (GLBA, PCI_Config, Zero, 0x0100) Field (GLBA, AnyAcc, NoLock, Preserve) { DVID, 16, Offset (0xCC), Offset (0xCD), PMEE, 1, , 6, PMES, 1 } Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake { Return (GPRW (0x0D, 0x04)) } Method (_DSW, 3, NotSerialized) // _DSW: Device Sleep Wake { // Override device sleep wake behavior to keep the device active Store (Arg0, PMEE) Store (One, PMES) // Ensure that the device remains in a powered state } Method (GPEH, 0, NotSerialized) { If (LEqual (DVID, 0xFFFF)) { Return (Zero) } If (LAnd (PMEE, PMES)) { Store (One, PWST) // Ensure the device status is set to powered on Store (One, PMES) // Ensure the device is maintained in an active state Notify (GLAN, 0x02) // Notify device wake } } Method (_PS0, 0, NotSerialized) // Power On { // Override power state to keep device ON Return (Zero) } Method (_PS3, 0, NotSerialized) // Power Off { // Prevent the device from powering off Return (Zero) } }
  2. 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."
  3. 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
  4. @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^^..
  5. @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
  6. Here comes pic from XP SP2 bit64 on GPT harddisk on pur UEFI with working(!) graphik, nice work from Gelip @reboot12 waaoohh.. Dietmar
  7. @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
  8. @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
  9. @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
  10. @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" ^^..
  11. @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.
  12. @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.
  13. @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
  14. @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
×
×
  • Create New...